The description of forms to be displayed on internet browsers via the World Wide Web is typically accomplished by the use of Dynamic Hypertext Markup Language (DHTML). DHTML is a product of the Microsoft Corporation of Redmond, Wash. DHTML incorporates the concept of the Form as a means of presenting Graphical User Interface (GUI) controls for manipulation by the user. DHTML documents contain tags representing user interface devices, such as input text boxes etc., known as controls. The controls may initially be blank, or information may be placed in the controls when the form is initially displayed. The initial data for any of the controls is usually transmitted with the DHTML document along with the control tag. An example of a DHTML statement having an inputbox control with the data “19344” embedded in the tag might be written as:<INPUT ID=ctlZipCode>19344</INPUT>
The user, in turn, may edit or enter new information into these controls. When the user is done, the contents of the GUI controls, is collected by the Web browser and forwarded as part of the Universal Resource Locator (URL) to the Web server in the form of control name/control value pairs.
Often, such forms are used to display and collect information related to a database. The database may contain tables, each table containing a collection of records, each record containing a collection of fields. When used in this manner, it is necessary to associate a control on the form with a corresponding piece of data in the database. Data binding refers to a software subroutine which associates data contained within a database with other information that is relevant to that data, including the data's location within the form, i.e. the control used to display and/or edit that data.
Currently, data binding relies on an architecture having four components, namely a data source object (DSO), data consumers, a binding agent and a table repetition agent. In order to bind database data to control elements present on an HTML page, a DSO, which represents the database, must exist on that page. To identify desired data within the database, the DSO requires selection information in some form. For example, the DSO may require an Open Database Connectivity (OBDC) string and a Structured Query Language (SQL) statement or only a Universal Resource Locator (URL). SQL is discussed in SQL—The Complete Reference by James R. Groff and Paul N. Weinberg, McGraw-Hill Professional Publishing (1999) ISBN 007-211-8458.
The data in the DSO may also be defined using Extensible Markup Language (XML). XML is discussed in Essential XML: Beyond Markup by Don Box, Aaron Skonnard and John Lam, Addison-Wesley Publishing Co. (2000) ISBN 020-170-9147. The XML DSO is a read only data provider. In order to use an XML DSO one must add a Java applet element to the HTML form page. Java is a product of Sun Microsystems, Inc of Palo. Alto, Calif. A param tag within the HTML form page specifies the location of the applet element. The XML DSO retrieves XML database data from a specified location, possibly from an external server computer via a network connection, parses the data, and provides the data to the bound control elements on the page. In this manner, the data consuming elements (the control elements) are isolated from the details of XML.
The Microsoft DHTML data binding software utilizes the Microsoft ActiveX Data Object (ADO) programming model which is discussed in Understanding ActiveX and OLE by David Chappell, published by the Microsoft Press, Redmond, Wash., ISBN 1-572-31216-5. The architecture of the existing state of the art, as practiced by Microsoft, is depicted in FIG. 1. The ADO programming model is a recordset model. The ADO recordset contains two components, namely a collection of Fields and a collection of Properties. Each record within an ADO recordset has a collection of Fields. The Fields collection is the default collection for an ADO recordset object. Each Field has a Name, Value and Count property. The Count property indicates the number of Fields in the collection. In the ADO recordset Properties collection each property has a Name, Type and Value. The ADO programming model permits only serial addressing of a record set, that is, only one record set at a time is accessible. One result of using the ADO protocol is that there is no practical method of binding one group of data control elements to more than one recordset object.
In the context of forms, a group of data control elements is a tabular grouping of data control elements that may be aligned either vertically and/or horizontally. A control element is defined as an element for display in a user interface display image, such as a form, questionnaire, web page, browser, spreadsheet, document or any other display, of data displayed for or entered by the user. The control element prompts a user to either make a selection or enter data. A desired presentation grouping of data, such as object oriented hierarchically arranged data, on a form can require data from several underlying recordset objects. The Microsoft ADO record set model does not integrate well with an object oriented hierarchical data buffer structure insofar as an HTML document builder must write code to manipulate multiple dataset objects, also called view objects, in order to bind the desired data to corresponding controls in the HTML form used for presentation formatting.
When an existing DHTML document is sent by a server to a client machine the document may already have embedded data. The client's web browser subsequently receives and displays whatever data is already contained in the server generated document. The user can then alter this displayed data. A form which has some of its data altered by the client user is returned to the server in its entirety when the user is finished. That is, both the data and the underlying form is retransmitted to the server. The repeated sending of redundant information between the server and client computers regarding a largely static form creates unnecessary network traffic.
Numerous examples of data binding protocols exist. U.S. Pat. No. 6,014,677, entitled DOCUMENT MANAGEMENT DEVICE AND METHOD FOR MANAGING DOCUMENTS BY UTILIZING ADDITIVE INFORMATION, issued to Hayashi et al. discloses a binding information creating device which associates a document with subsequent evaluation data based on earlier information contained within the document. A tag template is defined by an onscreen editor, and a tag template database is created to associate coinciding tags with the same document.
U.S. Pat. No. 5,940,075, entitled METHOD FOR EXTENDING THE HYPERTEXT MARKUP LANGUAGE (HTML) TO SUPPORT ENTERPRISE APPLICATION DATA BINDING, issued to Mutschler, III et al. discloses a web server program and associated database for storing description language of a form to be displayed. The server is coupled to a host having a CPU executing a legacy application containing the form. The server opens the form and associates data names with data values received from the host and sends them to the client.
U.S. Pat. No. 6,023,271, entitled FRAMEWORK FOR BINDING DATA VIEWERS/DATA MANIPULATION WITH ONE TO MANY OBJECTS THROUGH INTROSPECTION, issued to Quaeler-Bock et al., discloses a data structure that enables a client application to bind a set of GUI components to the attributes of at least one Business Object (BO).
U.S. Pat. No. 5,555,365, entitled METHOD AND SYSTEM FOR OPTIMIZING STATIC AND DYNAMIC BINDING OF PRESENTATION OBJECTS WITH THE OBJECT DATA THEY REPRESENT, issued to Selby et al. discloses the creation of a table that specifies relationships between GUI objects and the application object. Each time the application object is initialized the table is used to associate GUI objects to objects within the application object.
U.S. Pat. No. 5,430,836, entitled APPLICATION CONTROL MODEL FOR COMMON USER INTERFACE ACCESS, issued to Wolf et al., discloses an Application Control Module (ACM) that is executable by the applications. The ACM includes functional elements for initializing the data in the application, drawing or presenting a display screen defined by the data, running or processing user input events in accordance with the operation defined by the data, and closing the application.
U.S. Pat. No. 5,832,532, entitled MODEL INDEPENDENT AND INTERACTIVE REPORT GENERATION SYSTEM AND METHOD OF OPERATION, issued to Kennedy et al. discloses an interactive report generation system that includes a compiler, an evaluator, a renderer, and model interface functions. The compiler receives report, layout, and worksheet definitions, accesses model interface functions, and generates a report template. The evaluator receives the report template, accesses model interface functions, accesses a user model, and generates a report instance. A renderer receives the report instance in order to display and allow interaction with that report instance.
A presentation grouping of data on a form can originate from several underlying dataset objects. It is desirable that any desired control grouping should able to be achieved without the need to create additional view objects for each specific display arrangement. This would facilitate the use of business objects as they are defined in the application server without requiring the transformation of the data into an alternate buffer structure, or additional programming of view or dataset objects.